Repository navigation
feat: instant-paint boot loading bar - #14
Merged
Merged
Conversation
The app showed a blank black screen until the ~194KB-gzipped entry bundle
(Three.js) downloaded, parsed, and rendered the first frame — no feedback.
Add an inline boot loader: an overlay + critical CSS live directly in
index.html (a <head> <style> + #boot-loader markup Vite passes through into
the built HTML ahead of the module <script>), so the loading bar paints on
the FIRST paint, before any JS downloads. The fill advances toward 92% on a
pure-CSS animation; src/main.js snaps it to 100% and fades the overlay out
on the first rendered frame (a one-shot after the first renderer.render in
animate(), which runs synchronously at module eval — before window.__app is
set, so the overlay is pointer-events:none/removed before any UI interaction).
This is a perceived-load win (First Contentful Paint: blank -> instant). The
JS payload is unchanged: Three.js is required for the first frame and the
depth model already lazy-loads (no model bytes at boot).
Smoke test asserts the loader ships in the raw server HTML (fetched via
page.request.get('/'), so a JS-injected node can't satisfy it) AND is gone
once the app boots — non-tautological only together.
Autopilot: user-directed polish (boot loading bar)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
User-directed polish: make the page load faster + a nice loading bar that starts when you open the page.
Today the app is a blank black screen until the ~194 KB-gzipped entry bundle (essentially all Three.js) downloads, parses, and renders the first frame — zero feedback. This adds an inline, instant-paint boot loading bar.
index.html(a<head><style>+#boot-loadermarkup). Vite passes both through untouched into the built HTML, ahead of the module<script>, so the bar paints on the first paint — before any JS downloads.src/main.jssnaps it to 100% and fades the overlay out on the first rendered frame (a one-shot after the firstrenderer.renderinanimate()).animate()runs synchronously at module eval, beforewindow.__appis assigned — so the overlay is alreadypointer-events:none/ removed before any UI interaction, and it never covers#controls.Honest scope on "faster"
This is a perceived-load win (First Contentful Paint: blank → instant + progress feedback). The JS payload is unchanged — Three.js is required to render the first frame, and the depth model already lazy-loads (
transformers.web, the ORT wasm, anddepth-workerare all separate on-demand chunks; no model bytes at boot). Shrinking Three.js / touching deps / build / CI config is out of scope per CLAUDE.md + STATUS.md, so I did not fabricate a bundle-size reduction.RED test (non-tautological)
New
tests/smoke.spec.jstest asserts, together:page.request.get('/'), so a JS-injected node can't satisfy it (proves it's up before JS);window.__appis ready (provesmain.jsdismisses it).Proven non-tautological: baseline (no loader) is RED on (1); an intermediate build with the loader in HTML but dismissal disabled was verified RED on (2) — the overlay stayed
visiblefor all retries.Full local suite: 14/14 green (
npm test, real Chromium + software WebGL).Independent adversarial verification
A separate read-only verifier (no access to my reasoning) could not refute the change. It confirmed the load-bearing safety property — dismissal is synchronous in the first
animate()call, before__appis set and before any test interacts, so the overlay can never intercept clicks on the control UI the other 13 tests drive. Two cosmetic nits only, both "not blockers, not regressions": a frozen bar on an already-broken boot path (a cosmetic improvement over today's black page; never affects a working app), androle="progressbar"withoutaria-valuenow(valid ARIA — omitted valuenow signals indeterminate).Review
/code-reviewhere launches a billed cloud Workflow; autopilot mandates local/not-billed unless opted in, so the diff was reviewed inline (+ the adversarial verifier above). No unresolved or judgment-call findings.Visual check
Verified on a real production build — frozen-loader screenshot shows the centered "LIVE DEPTH FIELD" title + a blue gradient fill (~92%) with a soft glow on the black background, matching the app's splat aesthetic.
Rollback
Pre-change HEAD:
789d6ae89cdead41dd48a40175676b00527fc32b🤖 Generated with Claude Code